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Abstract 


Currently,  there  is  no  standard  tool  designed  to  assist  Army  maneuver  battalions  in  daily 
forecasting  of  food,  water,  petroleum  products,  and  ammunition.  Support  platoon  leaders  and  battalion 
logistics  officers  forecast  logistical  requirements  primarily  by  hand  or  with  tools  developed  “in-house”. 
Because  these  personnel  do  not  get  the  training  needed  to  do  accurate  forecasting,  they  typically  seek  the 
assistance  of  Forward  Support  Battalion  (FSB)  company  commanders  through  informal  channels.  The 
goal  is  to  achieve  the  most  accurate  supply  forecast  possible,  but  under  the  current  system,  over¬ 
forecasting  or  under-forecasting  is  common,  which  can  result  in  unnecessary  risk  to  the  mission,  units,  or 
support  personnel,  as  well  as  increasing  stress  on  the  logistics  chain.  Currently,  the  only  automated  tools 
available  are  designed  for  brigade  level  and  above. 

The  Support  Leader’s  Digital  Assistant  (SLDA)  began  as  an  Excel  spreadsheet  designed  to 
forecast  re-supply  needs  based  on  existing  planning  figures,  and  was  subsequently  developed  for  the  Palm 
platform  as  a  test  of  concept.  The  goal  of  this  phase  of  development  was  to  expand  its  forecasting 
capabilities,  adjust  the  model’s  parameters  to  interface  with  existing,  higher  echelon  automated  systems, 
and  to  facilitate  its  development  for  the  PocketPC  platform. 


About  the  Author(s) 

MAJOR  WILEY  P.  RITTENHOUSE  is  an  instructor  in  the  Department  of 
Mathematics  serving  as  an  analyst  in  the  Operations  Research  Center  of  Excellence  at  the 
United  States  Military  Academy  (USMA),  West  Point,  New  York.  He  reeeived  a  BS  in 
Mathematies  from  Kansas  State  University  in  1994  and  a  MS  in  Statistics  from  Tulane 
University  in  2003.  His  research  interests  include  the  application  of  statistical  analyses  and 
simulation  to  operations  research.  His  email  address  is  Wilev.Rittenhouse@usma.edu. 

MAJOR  ELIZABETH  W.  SCHOTT  is  assigned  to  the  Army  Training  and 
Doctrine  Command  Analysis  Center- White  Sands  Missile  Range,  New  Mexico.  She  has  a 
bachelor’s  degree  in  mathematics  from  the  USMA  and  a  master’s  degree  in  industrial 
engineering  from  the  Georgia  Institute  of  Technology.  She  is  a  graduate  of  the  Quartermaster 
Officer  Basic  Course,  the  Combined  Logistics  Officers  Advanced  Course,  and  the  Army 
Command  and  General  Staff  Officer’s  Course.  Her  e-mail  address  is 
Elizabeth.Achott@us.armv.mil. 

MAJOR  HOLLY  F.  WEST  is  an  assistant  professor  of  systems  engineering  at  the 
U.S.  Military  Academy  (USMA).  She  has  a  bachelor’s  degree  in  economics  from  the  USMA 
and  a  master’s  degree  in  business  administration  from  the  University  of  Kentucky.  She  is  a 
graduate  of  the  Quartermaster  Officer  Basic  Course  and  the  Combined  Logistics  Officers 
Advanced  Course.  Her  e-mail  address  is  Hollv.West@usaac.armv.mil. 

LIEUTENANT  COLONEL  MICHAEL  J.  KWINN,  JR.,  is  an  Associate  Professor 
in  the  Department  of  Systems  Engineering  and  Director  of  the  Operations  Research  Center  of 
Excellence  at  the  United  States  Military  Academy,  West  Point.  He  has  a  B.S.  Degree  from 
USMA,  M.S.  degree  in  Systems  and  Industrial  Engineering  from  the  University  of  Arizona 
and  a  Ph.D.  in  Management  Science  and  Information  Systems  from  the  University  of  Texas, 
Austin.  His  research  interests  include  operational  assessment  methodology,  effieiency 
analysis,  recruiting  analysis  especially  marketing  effects  and  capability  analysis  and 
modeling.  Lieutenant  Colonel  Kwinn  may  be  contacted  at  Michael.Kwinn@usma.edu. 


IV 


Acknowledgements 


Thanks  to  MAJ  Jim  Jackson  (Department  of  Electrical  Engineering  and  Computer 
Science,  USMA)  for  his  role  in  the  early  development  of  the  SLDA  concept.  His  efforts 
were  instrumental  in  the  development  of  the  initial  concept  and  early  test  versions  of  the 
SLDA. 


Table  of  Contents 


Abstract . iii 

About  the  Author(s) . . . iv 

Acknowledgements . v 

List  of  Figures . viii 

List  of  Tables . ix 

Chapter  1:  Introduction . 1 

1.1.  Background . 1 

1.2.  Purpose . ; . 1 

1.3.  Document  Conventions . 1 

1.4.  Intended  Audience  and  Reading  Suggestions . 2 

1.5.  Scope  of  the  Development  Project . 2 

1.6.  Overview  of  Document . 2 

Chapter  2:  Overall  Description . 3 

2.1.  Product  Perspective . 3 

2.2.  Product  Functions . 3 

2.3.  User  Classes  and  Characteristics . 4 

2.4.  Operating  Environment . 4 

2.5.  Assumptions  and  Dependencies . 4 

2.6.  Overview  of  Data  Requirements . 4 

2.6.1.  Inputs . 4 

2.6.2.  Outputs . 5 

2.6.3.  Stored  Data . 6 

2.7.  User  View  of  Product  Use . 6 

Chapter  3:  External  Interface  Requirements . 7 

3.1.  User  Interfaces . 7 

3.2.  Hardware  Interfaces . 7 

3.3.  Software  Interfaces . 7 

3.4.  Communications  Interfaces . 7 

Chapter  4:  System  Features . 8 

4.1.  The  Main  Function  Selection  Dialog  (MFSD) . 8 

4.1.1.  Description . 8 

4.1.2.  Stimulus/Response  Sequences . 8 

4.2.  The  SLDA  Set-Up  Dialog . 8 

4.2.1.  Description . 8 

4.2.2.  Stimulus/Response  Sequences . 8 

4.2.3.  Functional  Requirements . 13 

4.3.  Class  I  Forecasting  Dialog . 15 

4.3.1.  Description . 15 

4.3.2.  Stimulus/Response  Sequences . 15 

4.3.3.  Functional  Requirements . 17 

4.4.  Class  III  Forecasting  Dialog . 18 

4.4.1.  Description . 18 

4.4.2.  Stimulus/Response  Sequences . 18 


VI 


4.4.3.  Functional  Requirements . 20 

4.5.  Class  V  Forecasting  Dialog . 20 

4.5.1.  Description . 20 

4.5.2.  Stimulus/Response  Sequences . 21 

4.5.3.  Functional  Requirements . 22 

4.6.  Requisition  &  Report  Generation  Dialog . 22 

Chapter  5:  Other  Non-Functional  Requirements . 24 

5.1.  Security  Requirements . 24 

5.2.  Special  User  Requirements . 24 

5.2.1.  Backup  and  Recovery . 24 

5.2.2.  Data  Retention . 24 

5.2.3.  User  Training . 24 

Chapter  6:  Future  Development . 25 

6.1.  Validate  and  Verify  Class  I  Forecasting  Approach . 25 

6.2.  Develop  historical  data  forecasting  for  Classes  III  and  V . 25 

6.3.  Resource  Planning . 25 

6.4.  Automated  Requisitioning . 25 

Appendix  A:  SLDA  Diagrams . 26 

Appendix  B:  Functional  Hierarchy . 30 

Appendix  C:  Equations . 32 

Bibliography . 34 


vii 


List  of  Figures 


Figure  1:  SLDA  Overall  Structure . 3 

Figure  2:  Diagram  of  Set-Up  Dialog . 26 

Figure  3:  Diagram  of  Class  I  Forecast  Dialog . 27 

Figure  4;  Diagram  of  Class  III  Forecast  Dialog . 28 

Figure  5:  Diagram  of  Class  V  Forecast  Dialog . 29 


viii 


List  of  Tables 

Table  1 :  Data  Input  Requirements . 4 

Table  2:  Data  Output  Requirements . 5 

Table  3:  Source  Data  Tables . 6 


IX 


Chapter  1:  Introduction 


1.1.  Background. 

The  SLDA  concept  is  based  on  the  work  of  MAJ  Holly  West  and  MAJ  Libby  Schott  (West, 
Schott,  Army  Logistician,  July-August  2005)  with  the  initial  prototype  developed  by  Dr.  Roy 
Boggs  from  Florida  Gulf  Coast  University  in  2002.  In  its  second  stage,  the  project  was  presented 
as  the  Requirements  Analyzer  (REA)  (West,  Schott,  MORSS,  2004)  which  culminated  in  a 
second  prototype  written  for  the  Palm  platform  by  MAJ  Jim  Jackson  (Department  of  Electrical 
Engineering  and  Computer  Science,  U.S.  Military  Academy,  West  Point).  The  authors  also 
visited  personnel  at  the  Stiyker  Brigade  Combat  Team  at  Fort  Wainwright,  Alaska  to  present 
the  concept  to  them  and  solicit  their  input. 

1.2.  Purpose. 

This  document  provides  the  software  requirements  specification  (SRS)  for  the  Support  Leader’s 
Digital  Assistant  (SLDA),  version  1 .  The  SLDA  is  to  be  a  tool  available  to  leaders  in  lower- 
echelon  combat  units  who  are  responsible  for  logistics  operations.  It  should  accept  and  store 
information  on  unit  personnel  and  equipment,  climate,  ration  requirements,  mission  data, 
equipment  status,  mission-oriented  protective  posture  (MOPP),  on-hand  supply  data,  and 
date/time.  It  should  generate  forecasts  for  (primarily)  Class  I  (rations  and  water).  Class  III 
(petroleum  products,  both  bulk  and  packaged),  and  Class  V  (ammunition)  supplies  as  well  as 
(secondary)  certain  critical  Class  II  (individual  equipment)  items  and  Class  IV  (construction  and 
barrier  materials).  Finally,  it  should  generate  requisition  data,  reports,  and  keep  a  history  of 
forecasts  and  requisitions.  The  purpose  of  this  document  is  to  describe  the  SLDA  from  an 
overall  point  of  view,  describing  how  it  should  be  used,  how  it  should  behave,  its  operating 
environment,  and  its  limitations. 

1.3.  Document  Conventions. 

Many  of  the  diagrams  in  this  document  are  shown  in  Appendix  A,  due  to  their  large  size. 
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1.4.  Intended  Audience  and  Reading  Suggestions. 

The  primary  intended  audience  for  this  document  is  the  developer  hired  under  contract  with  the 
Program  Manager,  Logistics  Information  Systems  (PM-LIS)  so  as  to  facilitate  the  application’s 
development  for  the  PocketPC  platform. 

1.5.  Scope  of  the  Development  Project. 

Many  of  the  details  regarding  the  objectives  and  benefits,  as  well  as  some  of  the  features  of  the 
SLDA  are  already  explained  in  the  paper  “The  Support  Leader’s  Digital  Assistant:  A  Tool  for 
the  Support  Platoon  Leader’’  (Rittenhouse,  Kwinn,  West,  2005).  The  logistical  forecasts  in  the 
SLDA  are  derived  initially  from  published  planning  values  (Edwards,  2000)  for  the  different 
classes  of  supply.  However,  as  the  SLDA  acquires  historical  data  from  repeated  forecasts,  it 
should  utilize  the  data  to  determine  a  forecast  based  on  actual  consumption  history. 

1.6.  Overview  of  Document. 

Chapter  2  provides  an  overall  description  of  the  SLDA,  along  with  its  functions  and  data 
requirements.  Chapter  3  briefly  discusses  external  interface  requirements.  Chapter  4  discusses 
system  features  in  detail.  Equations,  large  diagrams,  references,  and  a  list  of  abbreviations  can 
be  found  in  the  appendices. 
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Chapter  2 :  Overall  Description. 

2.1.  Product  Perspective. 

The  SLDA  is  intended  to  provide  leaders  in  eombat  units  a  means  of  determining  aecurate 
supply  forecasts  without  having  to  rely  on  outside  assistance.  Personnel  in  lower-echelon  units 
(battalion  and  below)  who  are  responsible  for  support  operations  are  usually  not  trained 
logisticians,  and  they  will  typically  need  to  seek  outside  assistance  to  determine  an  accurate 
forecast.  This  is  not  always  possible  due  to  the  tactical  situation.  The  SLDA  is  meant  to  provide 
these  leaders  with  “in-hand”  expertise  for  forecasting  their  support  needs,  and  to  provide  tools  to 
make  the  most  accurate  forecasts  possible  from  available  data.  The  SLDA  is  essentially  a  new 
product  -  it  has  been  developed  in  limited  form  to  test  the  concept,  but  the  intent  of  this 
document  (together  with  the  SDS)  is  to  provide  requirements  and  design  specifications  necessary 
to  develop  a  deployable  solution,  ready  to  put  into  the  hand  of  the  Army’s  combat  unit  support 
leaders.  Ultimately,  the  SLDA  should  become  an  integrated  part  of  the  Army’s  supply  chain 
management  system.  A  basic  application  structure  is  shown  in  Figure  1 . 


Figure  1:  SLDA  Overall  Structure 

2.2.  Product  Functions. 

The  SLDA’s  fimctional  hierarchy  is  given  in  Appendix  B. 


3 


2.3.  User  Classes  and  Characteristics. 


The  primary  user  class  for  the  SLDA  is  the  lower-echelon  combat  imit  support  officer,  usually 
the  support  platoon  leader,  the  battalion  S4,  or  the  SPO.  It  is  assumed  that  this  class  of  user  has 
no  formal  logistics  training. 

2.4.  Operating  Environment. 

The  SLDA  is  to  be  developed  for  use  on  the  PocketPC  platform. 

2.5.  Assumptions  and  Dependencies. 

It  is  assumed  that  the  application’s  requisition  data  will  be  passed  on  to  outside  organizations 
using  an  external  application,  so  the  SLDA  should  only  need  to  produce  the  necessary  requisition 
data  as  an  object  that  can  be  acted  upon  by  a  separate  application.  It  is  also  assumed  that  the 
SLDA  will  not  receive  personnel  or  maintenance  data  electronically  from  other  systems.  The 
quality  of  many  of  the  inputs  is  dependent  on  the  user  receiving  and  aggregating  good  data  from 
within  the  unit. 

2.6.  Overview  of  Data  Requirements. 

2.6,1.  Inputs. 

Table  1  describes  data  input  requirements.  If  a  main  input  also  includes  sub-inputs,  they  are 
listed  after  it  (indicated  in  the  center  column). 


Table  1:  Data  Input  Requirements 


Mam  Input 

Sub-Input 

Description 

Unit 

Information 

This  will  be  simply  a  text  entry  recording  the  unit  name  and  type. 

Personnel 

Data 

The  user  will  be  allowed  to  enter  personnel  count  values  for  each  24-hour  period  that 

falls  within  the  next  three  re-supply  periods  (i.e.  if  the  re-supply  interval  is  24  hours, 

there  will  be  personnel  counts  for  24, 48,  and  72  hours.  If  the  re-supply  interval  is 

48  hours,  there  will  be  counts  for  24,  48,  72,  96, 120,  and  144  hours).  The  user  will 

indicate  the  number  people  with  special  meal  requirements  (by  type)  for  each  24- 

hour  interval,  as  well  as  total  unit  count. 
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Sub-Input 

Description 

Climate 

The  user  will  select  the  appropriate  climate  type  for  each  re-supply  interval  (hoEarid, 

hoEtropical,  temperate,  or  cold). 

Equipment 

User  will  select  number  of  vehicles  by  type  from  a  general  list.  Vehicle  types  with  a 

count  of  zero  entered  will  not  be  visible  outside  the  set-up  dialog. 

Ration 

Cycles 

User  will  select  the  three-character  ration  cycle  for  each  24-hour  period  that  falls 

within  the  next  three  re-supply  periods. 

Mission 

:bata 

.  ..  . 

This  data  is  entered  into  a  dynamicTist.  The  main  index  is  time  and  is  only  entered 

in  whole  hours.  A  new  cntiy  is  created  only  if  one  of  the  following  elements 

changes  (all  elements  plus  time  are  given  in  each  list  entry). 

Mission  -  ^ 

.bype;:vy:y{?; 

offensive,  defensive,  or  movement 

Mission 

Terrain 

cross-country,  road,  or  idle 

MOPP 

Level 

0, 1-IV,  or  unknown 

'Equipment  , 

Status 

- 

Deadlined 

Equipment 

The  user  should  be  able  to  enter  the  number  of  deadlined  vehicles  or  systems  by 
type.  ,  r  .  ^  . 

' 

On-Hand 

Supplies  ' 

The  user  should  be  able  to  enter  on-hand  quantities  for  MREs,  water  (bulk  and 

bottled),  fuel  (by  type),  package  POL,  and  ammunition  (by  type). 

2.6.2.  Outputs. 

Table  2  describes  data  output  requirements.  If  a  main  input  also  includes  sub-inputs,  they  are 
listed  after  it  (indicated  in  the  center  column). 


Table  2:  Data  Output  Requirements 


Main 

Output 

Sub-Output 

Description 

Forecasts 

Forecasts  are  generated  for  the  next  three  re-supply  operations  (for  planning 

purposes). 

Class  I 

MREs  (by  case  and  by  meal).  Hot  A  (by  meal),  UGR  (by  meal),  water  (bulk  and 

Forecast 

bottled). 

Class  m 

Forecast 

Bulk  fuel  (by  type)  and  package  POL  (by  type).  ;  ^  ; 

Sub-Output 

Description 

Class  V 

Forecast 

Ammunition  (by  type). 

Requisitions 

For  Classes  I,  III  and  V,  only  generated  once  for  each  re-supply  operation  (not  for 

each  forecast  interval). 

Reports 

Generate  reports  for  the  next  higher  echelon,  for  the  SPO,  and  to  show  historical 

data. 

2.6.3.  Stored  Data. 

There  will  be  several  tables  of  source  data  that  will  be  called  upon  to  facilitate  data  input  and 
forecasting.  They  are  listed  in  Table  3. 


Table  3:  Source  Data  Tables 


Table 

,  Description 

Vehicle  Data 

Includes  type,  fuel  type,  fuel  capacity,  fuel  consumption  rates,  and  any  mounted  weapons 

integral  to  the  system. 

Weapons  Data 

Includes  type  and  ammunition  requirements. 

Ammunition 

Data 

Includes  DODIC,  description,  and  round  count  per  container. 

Planning  Values 

For  Class  I,  III  and  V  (used  for  early  forecasting  before  accumulated  historical  data  can  be 

used). 

2.7.  User  View  of  Product  Use. 

The  primary  user  would  employ  the  SLDA  to  assist  in  completing  the  unit’s  daily  LOOP  AC. 
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Chapter  3:  External  Interface  Requirements 


3.1.  User  Interfaces. 

The  primary  interface  with  the  SLDA  should  be  the  screen  interface  of  the  PocketPC  device. 
Because  of  this,  entry  of  raw  data  (numeric  or  text)  should  be  minimized  by  making  use  of  pull¬ 
down  menus  (for  short  lists  of  options)  or  “spinners”  (for  longer  lists,  usually  numeric)  whenever 
possible. 

3.2.  Hardware  Interfaces. 

Determined  by  PM-LIS/TLDD 

3.3.  Software  Interfaces. 

Determined  by  PM-LIS/TLDD 

3.4.  Communications  Interfaces. 

Determined  by  PM-LIS/TLDD 
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Chapter  4:  System  Features. 

4.1.  The  Main  Function  Selection  Dialog  (MFSD). 

This  should  be  the  application’s  top  level,  providing  direct  access  to  all  primary  functions. 

4.1.1.  Description. 

This  dialog  presents  the  user  with  buttons  that  provide  access  to  the  following  sub-functions: 
SLDA  Set-Up  Dialog,  Class  I  Forecasting  Dialog,  Class  III  Forecasting  Dialog,  Class  V 
Forecasting  Dialog,  Requisition  &  Report  Generation  Dialog,  and  Exit  the  Application. 

4.1.2.  Stimulus/Response  Sequences. 

When  the  user  clicks  any  one  of  the  buttons  in  this  dialog,  the  top-level  or  entry  dialog  for  the 
associated  sub-function  should  appear.  When  all  processes  for  the  sub-function  are  completed, 
the  user  should  be  presented  with  an  exit  button  that  will  return  the  SLDA  to  the  MFSD. 

4.2.  The  SLDA  Set-Up  Dialog. 

4.2.1.  Description. 

This  dialog  allows  the  user  to  enter  or  select  data  that  is  needed  for  supply  forecasting.  Most  of 
the  data  entered  here  will  not  need  to  be  changed  frequently.  The  top  level  in  this  dialog  is  a 
panel  of  user-selectable  buttons  that  give  the  user  access  to  dialogs  for  “Unit  Information”, 
“Equipment  Data”,  Basic  Load  Data”,  and  “Planning  Values”.  Once  the  user  has  completed  the 
steps  in  this  dialog,  the  “Unit  Equipment  Table”  will  be  populated  with  equipment  data  based  on 
built-in  default  information.  This  table  will  be  available  for  modification  in  the  “Equipment 
Data”  dialog. 

4.2.2.  Stimulus/Response  Sequences. 

4.2.2. 1 .  Unit  Information. 

This  dialog  consists  of  five  sub-dialogs  that  are  linked  in  sequence,  with  “next”,  “back”,  and 
“finished”  buttons  to  allow  the  user  to  navigate  through  the  sequence.  Once  the  user  selects 
“finished”  on  the  final  sub-dialog,  the  program  returns  to  the  top  level  in  the  SLDA  Set-Up 
Dialog. 
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4.2.2. 1.1.  Unit  Name. 


Stored  as  text.  This  information  is  referenced  for  report  titles.  A  “next”  button  should  take  the 
user  to  the  “Unit  Type”  dialog. 

4.2.2. 1 .2.  Unit  Type. 

Selected  from  a  list  of  options  (version  1 :  infantry  or  armor  battalion),  which  sets  the  appropriate 
flag  indicating  imit  type.  The  flag  value  will  be  used  to  filter  out  unneeded  vehicle  information 
stored  in  the  Equipment  Data  Table.  The  intent  of  this  is  to  quickly  create  a  “pre-built”  list  of 
vehicle  types  and  quantities  based  on  default  information  (actually  done  in  three  steps  using  the 
“Unit  Type”,  “Task  Organization”,  and  “Attachments  &  Detachments”  sub-dialogs)  and 
representing  a  complete  table  of  assigned  vehicles.  A  “next”  button  should  take  the  user  to  the 
“Task  Organization”  dialog.  A  “back”  button  should  return  the  user  to  the  “Unit  Name”  dialog. 

4.2.2. 1.3.  Task  Organization. 

User  selects  the  number  of  each  type  of  company-sized  unit  in  the  battalion  from  a  pull-down 
list.  Selected  values  are  used  to  determine  the  quantity  of  each  type  of  vehicle  based  on  default 
values  for  company-sized  units.  These  values  are  used  to  add  vehicle  coiints  to  the  list  of 
equipment  that  results  from  the  “Unit  Type”  dialog.  A  “next”  button  should  take  the  user  to  the 
“Attachments  &  Detachments”  dialog.  A  “back”  button  should  return  the  user  to  the  “Unit 
Type”  dialog. 

4.2.2. 1.4.  Attachments  &  Detachments. 

User  selects  the  number  of  each  type  of  company  or  platoon  sized  units  that  are  attached  to  the 
battalion  from  pull-down  lists.  Selected  values  are  used  to  further  modify  the  quantities  for 
equipment  types  that  resulted  from  the  “Task  Organization”  dialog.  A  “next”  button  should  take 
the  user  to  the  “Re-Supply  Interval”  dialog.  A  “back”  button  should  return  the  user  to  the  “Task 
Organization”  dialog. 

4.2.2. 1 .5.  Re-Supply  Interval. 

User  selects  from  two  “radio  buttons”  the  re-supply  interval  that  the  unit  uses.  Radio  button 
options  should  be  “24  hours”  or  “48  hours”.  A  flag  is  set  depending  on  the  selection  made.  This 
flag  will  be  used  in  forecasting  calculations.  A  “finished”  button  should  take  the  user  to  the  top- 
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level  dialog.  A  “back”  button  should  return  the  user  to  the  “Attachments  &  Detachments” 
dialog. 

4.22.2.  Equipment  Data. 

This  dialog  consists  of  two  main  dialogs  with  one  sub-dialog  each  that  are  linked  in  sequence, 
with  “next”,  “back”,  and  “finished”  buttons  to  allow  the  user  to  navigate  through  the  sequence. 
Once  the  user  selects  “finished”  on  the  final  dialog  or  sub-dialog,  the  program  returns  to  the  top 
level  in  the  SLDA  Set-Up  Dialog.  These  dialogs  are  intended  to  allow  the  user  to  make 
adjustments  and  additions  to  the  pre-populated  table  resulting  from  the  dialogs  described  in 
sections  4.2.2. 1.2,  4.2.2. 1.3,  and  4.2.2. 1.4. 

4.2.2.2. 1 .  Adjust  Vehicle  Quantities. 

This  dialog  calls  up  the  data  stored  in  the  “Unit  Equipment  Table”  and  allows  the  user  to  directly 
edit  the  quantities  for  each  vehicle  type.  Any  changes  should  be  stored  back  in  the  “Unit 
Equipment  Table”.  The  data  should  be  presented  in  tabular  form.  A  button  marked  “Enter 
additional  vehicles  &  quantities”  should  take  the  user  to  the  “Enter  Additional  Vehicles  & 
Quantities”  sub-dialog.  A  “next”  button  should  take  the  user  to  the  “Adjust  Weapon  Quantities” 
dialog. 

4.2.2. 2. 1 . 1 .  Enter  Additional  Vehicles  &  Quantities. 

This  sub-dialog  should  have  the  same  appearance  as  the  “Adjust  Vehicle  Quantities”  dialog.  The 
primary  difference  from  the  parent  dialog  is  that  the  user  should  be  able  to  select  from  a  pull¬ 
down  list  of  vehicles  (stored  in  the  “Equipment  Data  Table”)  any  vehicle  types  that  are  not 
currently  listed  in  the  “Unit  Equipment  Table”  as  a  result  of  completing  the  “Unit  Information” 
dialog.  The  user  should  then  be  able  to  enter  quantities  next  to  any  new  vehicle  type  entries. 

Any  changes  should  be  stored  back  in  the  “Unit  Equipment  Table”.  A  “next”  button  should  take 
the  user  to  the  “Adjust  Weapon  Quantities”  dialog. 

4.2.2.2.2.  Adjust  Weapon  Quantities. 

This  dialog  also  calls  up  the  data  stored  in  the  “Unit  Equipment  Table”  and  allows  the  user  to 
directly  edit  the  quantities  for  each  weapon  type.  Any  changes  should  be  stored  back  in  the 
“Unit  Equipment  Table”.  The  data  should  be  presented  in  tabular  form.  A  button  marked  “Enter 
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additional  weapons  &  quantities”  should  take  the  user  to  the  “Enter  Additional  Weapons  & 
Quantities”  sub-dialog.  A  “finished”  button  should  take  the  user  back  to  the  top  level  dialog. 

4.2.2.2.2. 1 .  Enter  Additional  Weapons  &  Quantities. 

This  sub-dialog  should  have  the  same  appearance  as  the  “Adjust  Weapons  Quantities”  dialog. 
The  primary  difference  from  the  parent  dialog  is  that  the  user  should  be  able  to  select  from  a 
pull-down  list  of  vehicles  (stored  in  the  “Equipment  Data  Table”)  any  weapon  types  that  are  not 
currently  listed  in  the  “Unit  Equipment  Table”  as  a  result  of  completing  the  “Unit  Information” 
dialog.  The  user  should  then  be  able  to  enter  quantities  next  to  any  new  weapon  type  entries. 
Any  changes  should  be  stored  back  in  the  “Unit  Equipment  Table”.  A  “finished”  button  should 
take  the  user  back  to  the  top  level  dialog. 

4.2.2.3.  Basic  Load  Data. 

This  dialog  consists  of  four  sub-dialogs  that  are  linked  in  sequence,  with  “next”,  “back”,  and 
“finished”  buttons  to  allow  the  user  to  navigate  through  the  sequence.  Once  the  user  selects 
“finished”  on  the  final  sub-dialog,  the  program  returns  to  the  top  level  in  the  SEDA  Set-Up 
Dialog.  Basic  Load  data  entries  are  stored  in  three  tables:  Class  I  Basic  Load  Data  Table,  Class 
in  Basic  Load  Data  Table,  and  Class  V  Basic  Load  Data  Table. 

4.2.2. 3.1.  Class  I  Basic  Load  Data. 

This  dialog  allows  the  user  to  select  basic  load  values  for  Class  I  supply  items.  All  entries 
should  be  integer  values.  The  dialog  should  allow  numeric  basic  load  entries  for  “MREs  per 
soldier”,  “Gallons  of  bulk  water  per  soldier”,  and  “Bottles  of  water  per  soldier”.  Data  should  be 
stored  in  the  Class  I  Basic  Load  Data  Table.  The  values  entered  are  stored  in  the  Class  I  Basic 
Load  Data  Table.  A  “next”  button  should  take  the  user  to  the  “Class  III  Basic  Load  Data” 
dialog. 

4.2.2.3.2.  Class  III  Basic  Load  Data. 

This  dialog  has  two  sub-dialogs,  one  for  bulk  POL  products  and  one  for  package  POL  products. 
POL  products  data  should  be  stored  in  a  POL  Products  Table.  Information  should  be  presented 
in  tabular  form.  If  device  storage  limitations  can  accommodate  it,  the  tables  in  both  sub-dialogs 
should  be  pre-populated  with  POL  product  data  based  on  the  vehicles  and  equipment  currently 
stored  in  the  Unit  Equipment  Table.  The  sub-dialog  for  bulk  POL  products  should  be  the  first 


11 


sub-dialog  to  appear  (it  should  appear  immediately  upon  entering  the  “Class  III  Basic  Load 
Data”  dialog).  The  user  then  enters  the  quantities  (in  gallons)  for  each  bulk  POL  product  type. 
The  user  should  also  be  allowed  to  select  additional  bulk  POL  product  types  and  assign 
quantities  if  a  eertain  product  was  not  in  the  pre-populated  list.  The  bulk  POL  product  sub¬ 
dialog  should  have  a  button  that  says  “Enter  package  POL  basic  loads”  which  takes  the  user  to 
the  package  POL  basic  load  sub-dialog.  This  sub-dialog  should  be  the  same  as  the  bulk  POL 
basic  load  sub-dialog,  except  that  unit  of  issue  should  be  included  in  the  POL  products  table. 

The  user  selects  the  number  of  units  for  each  package  POL  product  type.  A  provision  allowing 
the  user  to  add  additional  package  POL  products  and  quantities  should  be  implemented  in  the 
same  manner  as  the  bulk  POL  basic  load  sub-dialog.  Data  from  both  sub-dialogs  should  be 
stored  in  the  Class  III  Basic  Load  Data  Table.  On  the  package  POL  basic  load  sub-dialog,  a 
“next”  button  should  take  the  user  to  the  “Class  V  Basic  Load  Data”  dialog.  A  “back”  button 
should  return  the  user  to  the  “Class  I  Basic  Load  Data”  dialog. 

4.2.2.3.3.  Class  V  Basic  Load  Data. 

Ammunition  products  data  should  be  stored  in  an  Ammunition  Products  Table.  Information 
should  be  presented  in  tabular  form.  If  device  storage  limitations  can  accommodate  it,  the  tables 
in  the  dialog  should  be  pre-populated  with  ammunition  product  data  based  on  the  vehicles  and 
equipment  currently  stored  in  the  Unit  Equipment  Table.  The  user  enters  the  quantities  for  each 
ammunition  product  type.  The  user  should  also  be  allowed  to  select  additional  ammunition 
product  types  and  assign  quantities  if  a  certain  product  was  not  in  the  pre-populated  list.  Data 
should  be  stored  in  the  Class  V  Basic  Load  Data  Table.  A  “finished”  button  should  take  the  user 
to  the  top-level  dialog.  A  “back”  button  should  return  the  user  to  the  “Class  III  Basie  Load 
Data”  dialog. 

4.2.2.4.  Planning  Values. 

This  dialog  eonsists  of  three  sub-dialogs  that  are  linked  in  sequence,  with  “next”,  “back”,  and 
“finished”  buttons  to  allow  the  user  to  navigate  through  the  sequenee.  Onee  the  user  selects 
“finished”  on  the  final  sub-dialog,  the  program  returns  to  the  top  level  in  the  SLDA  Set-Up 
Dialog.  Planning  Value  data  entries  are  stored  in  three  tables:  the  Water  Plaiming  Values  Table, 
the  POL  Planning  Values  Table,  and  the  Ammo  Planning  Values  Table.  The  values  stored  in 
them  represent  the  default  eonsumption  values  for  these  items. 
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4.2. 2. 4. 1 .  Enter  Water  Planning  Values  Sub-Dialog. 

This  sub-dialog  should  allow  the  user  to  enter  values  for  water  consumption.  The  values  are 
given  in  terms  of  gallons/soldier/day,  and  depend  on  the  MOPP  level  and  the  climate  type 
(Edwards,  2000).  The  user  should  be  able  to  input  a  value  for  each  climate  type/MOPP  level 
combination.  A  button  marked  “Go  to  POL  Values”  should  take  the  user  to  the  “Enter  POL 
Planning  Values”  sub-dialog. 

4.2.2.4.2.  Enter  POL  Planning  Values  Sub-Dialog. 

This  sub-dialog  should  allow  the  user  to  enter  values  for  POL  product  consumption  (both  bulk 
fuel  and  package  POL).  A  button  marked  “Go  to  Ammo  Values”  should  take  the  user  to  the 
“Enter  Ammo  Planning  Values”  sub-dialog.  A  “back”  button  should  take  the  user  back  to  the 
“Enter  Water  Planning  Values”  sub-dialog. 

4.2.2.4.3.  Enter  Ammo  Planning  Values  Sub-Dialog. 

This  sub-dialog  should  allow  the  user  to  enter  values  for  ammunition  product  consumption.  A 
button  marked  “Finished”  should  take  the  user  back  to  the  top-level  dialog.  A  “back”  should 
take  the  user  back  to  the  “Enter  POL  Planning  Values”  sub-dialog. 

4.2.3.  Functional  Requirements. 

The  SLDA  Set-Up  dialog  will  require  three  read-only  tables  of  information:  an  Equipment  Data 
Table,  a  POL  Products  table,  and  an  Ammunition  Products  table.  Furthermore,  four  tables  that 
allow  read  &  write  functions  will  be  needed:  a  Unit  Equipment  Table,  a  Class  I  Basic  Load  Data 
table,  a  Class  III  Basic  Load  Data  table,  and  a  Class  V  Basic  Load  Data  table. 

4.2.3. 1 .  Equipment  Data  Table. 

This  table  should  contain  a  complete  list  of  all  vehicles,  systems,  and  individual  weapons  that 
depend  on  the  SLDA’s  three  primary  classes  of  supply  (I,  III,  and  V).  It  will  serve  as  the  basis 
for  the  Unit  Equipment  Table.  Any  equipment  that  will  not  be  considered  for  supply  forecasting 
does  not  need  to  be  included  in  the  table  (i.e.  the  current  concept  of  the  SLDA  does  not  consider 
aviation  units,  so  aircraft  do  not  need  to  be  included  in  this  table).  If  a  weapon  system  is  part  of 
a  combat  vehicle  (i.e.  the  main  gun  on  an  Ml  tank),  it  should  be  related  to  that  combat  vehicle  in 
the  table  and  not  listed  as  a  separate  system.  Individual  weapons  (like  the  Ml 6)  should  be  listed 
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as  separate  systems.  This  should  be  done  so  that,  for  example,  if  16  MlAl  tanks  are  entered 
during  set-up,  16  120mm  main  guns  would  be  automatically  included  (along  with  other  organic 
weapons),  and  they  would  not  need  to  be  entered  separately.  This  table  should  also  indicate,  for 
each  vehicle,  system,  or  weapon,  what  POL  or  ammunition  products  are  needed  for  its  operation. 
Data  from  this  table  will  be  read  into  the  Unit  Equipment  Table  based  on  user  input. 

4.2.3.2.  POL  Products  Table. 

This  table  should  contain  a  complete  list  of  all  bulk  and  package  POL  products.  It  will  serve  as 
the  basis  for  the  Class  III  Basic  Load  Data  Table. 

4.2.3.3.  Ammunition  Products  Table. 

This  table  should  contain  a  complete  list  of  all  ammunition  products.  It  will  serve  as  the  basis 
for  the  Class  V  Basic  Load  Data  Table. 

4.2.3.4.  Unit  Equipment  Table. 

This  table  contains  the  list  of  vehicles,  systems,  and  individual  weapons  that  are  actually  present 
in  the  unit  (including  attachments  &  detachments).  The  information  stored  here  is  read  from  the 
Equipment  Data  Table  based  on  user  input  entered  in  the  Unit  Information  dialog.  Relevant  data 
from  this  table  should  be  used  to  pre-populate  the  sub-dialogs  in  the  Equipment  Data  dialog  in 
order  to  speed  program  set-up.  It  should  also  be  used  to  pre-populate  the  sub-dialogs  for  POL 
and  ammunition  basic  loads  in  the  Basic  Load  Data  dialog. 

4.2. 3. 5.  Class  I  Basic  Load  Data  Table. 

All  information  pertaining  to  the  basic  loads  for  meals  and  water  (bulk  or  bottled)  should  be 
stored  here. 

4.2. 3. 6.  Class  III  Basic  Load  Data  Table. 

All  information  pertaining  to  the  basic  loads  for  bulk  and  package  POL  products  should  be 
stored  here. 

4. 2.3. 7.  Class  V  Basic  Load  Data  Table. 

All  information  pertaining  to  the  basic  loads  for  ammunition  products  should  be  stored  here. 
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4.2.3. 8.  Water  Planning  Values  Table. 

All  default  planning  values  for  water  products  should  be  stored  here.  The  table  should  allow  for 
the  updating  of  values  based  on  historical  data. 

4.2.3. 9.  POL  Planning  Values  Table. 

All  default  planning  values  for  POL  products  (bulk  fuel  and  package  POL)  should  be  stored  here. 
The  table  should  allow  for  the  updating  of  values  based  on  historical  data. 

4.2.3.10.  Ammo  Planning  Values  Table. 

All  default  planning  values  for  ammunition  products  should  be  stored  here.  The  table  should 
allow  for  the  updating  of  values  based  on  historical  data. 

4.3.  Class  I  Forecasting  Dialog. 

4.3.1.  Description. 

This  dialog  should  accept  user  input  personnel  counts,  MOPP  level,  and  ration  cycles.  It  should 
consist  of  four  sub-dialogs  (presented  to  the  user  in  sequence):  two  requiring  input  (Personnel, 
MOPP,  and  Climate  Data  sub-dialog,  and  Ration  &  Water  Data  sub-dialog),  one  for  input  review 
(Class  I  Data  Review  sub-dialog),  and  one  for  forecast  data  (Class  I  Forecast  Data  sub-dialog).  It 
should  also  allow  the  user  to  review  and  adjust  on-hand  quantities  of  Class  I  items.  Once  the 
user  has  the  opportunity  to  review  inputs,  the  dialog  should  produce  a  forecast  of  Class  I  supplies 
for  the  next  three  re-supply  periods.  All  user  inputs  and  program-generated  outputs  resulting 
from  this  dialog  should  be  placed  in  an  array  as  they  are  entered  or  calculated,  and  the  array 
should  be  stored  in  the  Forecast  History  Table  upon  exiting  the  dialog. 

4.3.2.  Stimulus/Response  Sequences. 

4.3.2. 1.  Personnel,  MOPP,  and  Climate  Data  sub-dialog. 

User  selects  the  number  of  soldiers  assigned  to  the  unit  for  each  of  the  three  re-supply  periods, 
separated  by  MRE  t3^e.  Spiimers  are  used  to  allow  the  user  to  change  the  values  for  each  field. 
User  selects  MOPP  level  for  each  day  included  in  the  next  three  re-supply  periods  using  pull¬ 
down  menus  (possible  inputs  are  0, 1,  II,  III,  IV,  Unknown).  User  selects  climate  type  for  each 
day  included  in  the  next  three  re-supply  periods  using  pull-down  menus  (possible  inputs  are  Hot- 
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Tropical,  Hot-Arid,  Temperate,  and  Cold).  A  button  marked  “Go  to  Ration  Data”  should  take 
the  user  to  the  “Ration  &  Water  Data”  sub-dialog. 

4.3.2.2.  Ration  &  Water  Data  sub-dialog. 

User  selects  the  ration  tj^e  (using  pull-down  lists)  for  each  day  and  each  meal  included  in  the 
next  three  re-supply  periods.  MRE  and  water  basic  load  data  should  be  shown  here  for  user 
review.  On-hand  quantities  for  each  type  of  MRE  (in  cases)  and  for  water  (in  gallons)  should  be 
shown,  and  the  values  should  be  calculated  by  taking  the  previous  day’s  on-hand  quantity  and 
subtracting  the  expected  consumption  over  the  last  24  hours.  The  user  should  be  allowed  to 
change  the  on-hand  quantities,  and  both  the  calculated  values  and  the  user-entered  values  should 
be  stored  in  the  array.  A  button  marked  “Go  to  Data  Review”  should  take  the  user  to  the  “Class  I 
Data  Review”  sub-dialog.  A  “back”  button  should  take  the  user  back  to  the  “Personnel,  MOPP, 
and  Climate  Data”  sub-dialog. 

4.3.2. 3.  Class  I  Data  Review  sub-dialog. 

This  sub-dialog  is  for  data  review  only.  On-hand  quantities  for  cases  of  MREs  (by  type)  and 
water  should  be  shown.  Personnel  coimts  for  each  day  within  the  next  three  re-supply  periods 
should  be  shown,  separated  by  the  type  of  MRE  they  require.  All  ration  cycles  for  the  next  three 
re-supply  period  should  be  shown.  MOPP  levels  and  climate  types  for  each  day  within  the  next 
three  re-supply  period  should  be  shown.  A  Button  marked  “Forecast”  should  take  the  user  to  the 
“Class  I  Forecast  Data”  sub-dialog.  A  “back”  button  should  return  the  user  to  the  “Ration  & 
Water  Data”  sub-dialog. 

4.3.2.4.  Class  I  Forecast  sub-dialog. 

The  purpose  of  this  dialog  is  to  present  the  forecast  recommendations  for  Class  I  items  to  the 
user.  It  should  present  the  forecasts  for  the  next  three  re-supply  periods.  Specifically,  it  should 
provide  a  foreeast  for  the  number  of  cases  of  MREs  (by  type),  rounded  up  to  the  nearest  integer. 
It  should  provide  a  forecast  of  other  meal  types  (i.e.  hot  A’s)  in  terms  of  individual  meals.  It 
should  provide  a  forecast  for  water  requirements,  both  bulk  and  bottled.  MRE  forecast 
calculations  are  given  in  equations  1,  2,  3,  and  4  (Appendix  C).  For  water,  there  are  two 
forecasting  methods  to  be  used: 
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4.32.4. 1 .  Forecast  based  on  default  planning  values. 


This  is  the  default  method,  and  will  be  used  any  time  there  is  insufficient  consumption  history,  or 
if  consumption  does  not  deviate  significantly  from  the  planning  values.  Planning  values  for 
water  are  given  in  gallon/soldier/day.  Water  forecast  calculations  are  given  in  equations  5,  6,  7, 
and  8  (Appendix  C). 

4.3.2.4.2.  Forecast  based  on  consumption-adjusted  values. 

The  calculations  for  this  forecast  are  the  same  as  those  based  on  the  default  planning  values, 
except  that  the  planning  value  F  will  be  different.  A  consumption-adjusted  value  is  substituted 
for  a  default  planning  value  if  the  consumption  over  a  certain  period  of  time  is  determined  to  be 
significantly  different  from  the  default  value.  This  is  done  using  the  following 
method: 


1 .  Five  forecasts  must  be  generated  using  the  same  values  for  climate  and 
MOPP. 

2.  From  the  five  forecast  records,  four  consumption  rate  values  are 
calculated  using  equation  9. 

3.  The  mean  and  standard  deviation  of  the  four  consiunption  rate  values  is 
calculated. 

4.  A  “Student’s  f  ’  statistic  is  calculated  from  this  data  using  equation  10. 

5.  If  the  absolute  value  of  the  t-statistic  determined  in  step  4  is  greater  than 
3.182,  then  the  mean  value  calculated  in  step  3  is  substituted  for  the 
default  planning  value. 

6.  The  process  starts  over  (the  same  test  is  conducted  every  time  five 
forecasts  are  recorded  with  the  same  climate  and  MOPP  values). 


A  button  should  be  provided  on  this  dialog  to  take  the  user  back  to  the  MFSD. 

4.3.3.  Functional  Requirements. 

4.3. 3. 1 .  Class  I  Basic  Load  Data  table. 

See  paragraph  4.2.2.3.I. 

4.3.3.2.  Default  Consumption  Planning  Factors  Table  (Water). 

This  table  contains  the  planning  factors  as  shown  in  Edwards,  page  66.  Entry  arguments  for  the 
table  are  MOPP  level  and  climate  type. 
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4.3. 3.3.  Class  I  Daily  Forecast  Record. 

This  is  an  array  that  contains  all  inputs  and  outputs  relevant  to  the  current  forecast  (described  in 
section  4.3.2).  This  is  entered  as  a  record  in  the  Class  I  Forecast  History  Table.  A  date/time 
stamp  should  be  appended  to  the  record. 

4.3. 3.4.  Class  I  Forecast  History  Table. 

This  table  contains  a  copy  of  each  Class  1  Daily  Forecast  Record,  with  the  most  recent  record 
listed  on  top. 

4.4.  Class  III  Forecasting  Dialog. 

4.4.1.  Description. 

This  dialog  should  accept  user-input  vehicle  status  (number  of  deadlined  vehicles,  by  type), 
mission  data  (type,  duration  of  phase,  terrain),  and  on-hand  quantities  data.  It  should  consist  of 
five  sub-dialogs  (presented  to  the  user  in  sequence):  three  requiring  input  (Vehicle  Status  Dialog, 
Mission  Data  Dialog,  and  On-Hand  Quantities  Dialog),  one  for  input  review  (Class  III  Data 
Review  sub-dialog),  and  one  for  forecast  data  (Class  III  Forecast  Data  sub-dialog).  Once  the 
user  has  the  opportunity  to  review  inputs,  the  dialog  should  produce  a  forecast  of  Class  III 
supplies  for  the  next  three  re-supply  periods.  All  user  inputs  and  program-generated  outputs 
resulting  from  this  dialog  should  be  placed  in  an  array  as  they  are  entered  or  calculated,  and  the 
array  should  be  stored  in  the  Forecast  History  Table  upon  exiting  the  dialog. 

4.4.2.  Stimulus/Response  Sequences. 

4.4.2. 1.  Vehicle  Status  Sub-Dialog. 

User  is  presented  a  list  of  vehicles/systems  with  an  integer  field  to  the  right  of  the  nomenclature 
which  is  used  to  indicate  the  number  of  deadlined  vehicles/systems  of  that  type.  Spinners  are 
used  to  allow  the  user  to  change  the  values  for  the  deadline  coimt.  A  button  marked  “Go  to 
Mission  Data”  should  take  the  user  to  the  “Mission  Data”  sub-dialog. 

4.4.2.2.  Mission  Data  Sub-Dialog. 

This  sub-dialog  should  be  a  djmamic  list,  which  will  allow  the  user  to  enter  as  many  rows  as  are 
needed  to  account  for  mission  details  covering  the  next  three  re-supply  periods  (i.e.  for  a  unit 
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using  a  24-hour  re-supply  interval,  onee  the  time  accounted  for  in  the  “Mission  Duration”  field 
reaches  72  hours,  the  list  is  complete).  Each  row  should  have  a  field  for  “Mission  Type” 
(selections  are  made  from  a  pull-down  list),  “Mission  Duration”  (an  integer  field  controlled  by  a 
spinner;  duration  is  entered  to  the  nearest  whole  hour),  and  “Mission  Terrain”  (selections  are 
made  from  a  pull-down  list).  A  check  should  be  made  after  each  row  is  completed  to  see  if  the 
time  durations  in  the  “Mission  Duration”  column  sxun  to  three  re-supply  periods.  If  not,  another 
row  is  presented  requiring  user  input.  A  new  record  is  needed  if  either  the  mission  type  or 
mission  terrain  changes  (i.e.  no  two  consecutive  records  should  share  the  same  values  for 
mission  type  and  mission  terrain).  The  list  should  be  scrollable  if  the  number  of  rows  exceeds 
the  size  of  the  window.  A  button  marked  “Go  to  On-Hand  Quantities”  should  take  the  user  to 
the  “Class  III  On-Hand  Quantities”  sub-dialog.  A  “back”  button  should  take  the  user  back  to  the 
“Vehicle  Status”  sub-dialog. 

4.4.2. 3.  Class  III  On-Hand  Quantities  Sub-Dialog. 

This  sub-dialog  should  present  the  user  with  two  scrollable  lists  of  PQL  products  -  one  list  for 
bulk  POL  products  and  the  other  for  package  POL  products.  The  items  in  each  list  should  be 
based  on  the  POL  products  stored  in  the  “Class  III  Basic  Load  Data  Table”.  Each  row  should 
display  fields  identifying  the  POL  product  and  the  unit  of  issue,  and  an  integer  field  that  allows 
the  user  to  enter  or  change  the  on-hand  quantities.  A  button  marked  “Go  to  Data  Review”  should 
take  the  user  to  the  “Class  III  Data  Review”  sub-dialog.  A  “back”  button  should  take  the  user 
back  to  the  “Mission  Data”  sub-dialog. 

4.4.2.4.  Class  III  Data  Review  Sub-Dialog. 

This  sub-dialog  is  for  data  review  only,  and  is  presented  in  a  scrollable  window.  Only  vehicles 
or  systems  that  have  one  or  more  deadline  indicated  for  their  type  should  be  shown  (this  list  only 
needs  to  show  the  nomenclature  and  the  deadline  count).  The  mission  data  and  on-hand 
quantities  can  be  shown  as  they  were  entered.  A  Button  marked  “Forecast”  should  take  the  user 
to  the  “Class  III  Forecast  Data”  sub-dialog.  A  “back”  button  should  return  the  user  to  the  “Class 
III  On-Hand  Quantities”  sub-dialog. 
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4.4.2. 5.  Class  III  Forecast  Sub-Dialog. 


The  purpose  of  this  dialog  is  to  present  the  forecast  recommendations  for  Class  III  items  to  the 
user.  It  should  present  the  forecasts  for  the  next  three  re-supply  periods.  Specifically,  it  should 
provide  a  forecast  for  the  quantity  of  each  type  of  bulk  fuel  and  package  POL  products. 

4.4.3.  Functional  Requirements. 

4.4.3. 1.  Class  III  Basic  Load  Data  Table. 

See  paragraph  4.2.2. 3.2. 

4.4.3. 2.  Default  Consumption  Planning  Factors  Table  (POL  Products). 

This  table  contains  consumption  planning  values  and  entry  arguments  for  POL  products  that  are 
needed  for  the  vehicles  and  systems  stored  in  the  Unit  Equipment  Table. 

4.4.3 .3 .  Class  III  Daily  Forecast  Record. 

This  is  an  array  that  contains  all  inputs  and  outputs  relevant  to  the  current  forecast  (described  in 
section  4.4.2).  This  is  entered  as  a  record  in  the  Class  III  Forecast  History  Table.  A  date/time 
stamp  should  be  appended  to  the  record. 

4.4.3. 4.  Class  III  Forecast  History  Table. 

This  table  contains  a  copy  of  each  Class  III  Daily  Forecast  Record,  with  the  most  recent  record 
listed  on  top. 


4.5.  Class  V  Forecasting  Dialog. 

4.5.1,  Description. 

This  dialog  should  accept  user-input  weapon  status  (number  of  deadlined  weapons,  by  type),  and 
should  reflect  vehicle  status  entered  in  the  Class  III  Forecasting  Dialog  as  it  relates  to  weapons 
status  (i.e.  if  a  weapon  would  be  considered  deadlined  because  its  prime  mover  is  deadlined,  that 
information  should  be  presented  to  the  user).  It  should  use  the  same  mission  data  that  was 
entered  in  the  Class  III  Forecasting  Dialog.  It  should  accept  on-hand  ammunition  quantities  data. 
It  should  consist  of  five  sub-dialogs  (presented  to  the  user  in  sequence):  three  requiring  input 
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(Weapon  Status  Dialog,  Mission  Data  Dialog,  and  On-Hand  Quantities  Dialog),  one  for  input 
review  (Class  V  Data  Review  sub-dialog),  and  one  for  foreeast  data  (Class  V  Forecast  Data  sub¬ 
dialog).  Once  the  user  has  the  opportunity  to  review  inputs,  the  dialog  should  produce  a  forecast 
of  Class  V  supplies  for  the  next  three  re-supply  periods.  All  user  inputs  and  program-generated 
outputs  resulting  from  this  dialog  should  be  placed  in  an  array  as  they  are  entered  or  calculated, 
and  the  array  should  be  stored  in  the  Forecast  History  Table  upon  exiting  the  dialog. 

4.5.2.  Stimulus/Response  Sequences. 

4.5.2. 1.  Weapons  Status  Sub-Dialog. 

User  is  presented  a  list  of  weapons  with  an  integer  field  to  the  right  of  the  nomenclature  which  is 
used  to  indicate  the  number  of  deadlined  weapons  of  that  type.  If  a  weapon  is  deadlined  because 
of  its  prime  mover,  the  dialog  should  indicate  this  to  the  user.  Spinners  are  used  to  allow  the 
user  to  change  the  values  for  the  deadline  count.  A  button  marked  “Go  to  Mission  Data”  should 
take  the  user  to  the  “Mission  Data”  sub-dialog. 

4.5.2.2.  Mission  Data  Sub-Dialog/Review. 

This  data  is  entered  by  the  user  in  the  Class  UI  Forecast  Dialog,  and  should  be  presented  to  the 
user  here  for  review.  The  list  should  be  scrollable  if  the  number  of  rows  exceeds  the  size  of  the 
window.  A  button  marked  “Go  to  On-Hand  Quantities”  should  take  the  user  to  the  “Class  V  On- 
Hand  Quantities”  sub-dialog.  A  “back”  button  should  take  the  user  back  to  the  “Weapons 
Status”  sub-dialog. 

4.5.2.3.  Class  V  On-Hand  Quantities  Sub-Dialog. 

This  sub-dialog  should  present  the  user  with  a  scrollable  list  of  ammunition  products.  The  items 
in  the  list  should  be  based  on  the  ammunition  products  stored  in  the  “Class  V  Basic  Load  Data 
Table”.  Each  row  should  display  fields  identifying  the  ammunition  product  and  the  unit  of  issue, 
and  an  integer  field  that  allows  the  user  to  enter  or  change  the  on-hand  quantities.  A  button 
marked  “Go  to  Data  Review”  should  take  the  user  to  the  “Class  V  Data  Review”  sub-dialog.  A 
“back”  button  should  take  the  user  back  to  the  “Mission  Data”  sub-dialog. 
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4.5.2.4.  Class  V  Data  Review  Sub-Dialog. 

This  sub-dialog  is  for  data  review  only,  and  is  presented  in  a  scrollable  window.  Only  weapons 
that  have  one  or  more  deadline  indicated  for  their  tj^e  should  be  shown  (this  list  only  needs  to 
show  the  nomenclature  and  the  deadline  count).  The  mission  data  and  on-hand  quantities  can  be 
shown  as  they  were  entered.  A  Button  marked  “Forecast”  should  take  the  user  to  the  “Class  V 
Forecast  Data”  sub-dialog.  A  “back”  button  should  return  the  user  to  the  “Class  V  On-Hand 
Quantities”  sub-dialog. 

4.5.2. 5.  Class  V  Forecast  Sub-Dialog. 

The  purpose  of  this  dialog  is  to  present  the  forecast  recommendations  for  Class  III  items  to  the 
user.  It  should  present  the  forecasts  for  the  next  three  re-supply  periods.  Specifically,  it  should 
provide  a  forecast  for  the  quantity  of  each  type  of  bulk  fuel  and  package  POL  products. 

4.5.3.  Functional  Requirements. 

4.5.3. 1.  Class  V  Basic  Load  Data  Table. 

See  paragraph  4.2.2. 3. 3. 

4.5.3.2.  Default  Consumption  Planning  Factors  Table  (Ammunition  Products). 

This  table  contains  consumption  planning  values  and  entry  arguments  for  ammunition  products 
that  are  needed  for  the  weapons  stored  in  the  Unit  Equipment  Table. 

4.5. 3. 3.  Class  V  Daily  Forecast  Record. 

This  is  an  array  that  contains  all  inputs  and  outputs  relevant  to  the  current  forecast  (described  in 
section  4.5.2).  This  is  entered  as  a  record  in  the  Class  V  Forecast  History  Table.  A  date/time 
stamp  should  be  appended  to  the  record. 

4.5. 3. 4.  Class  V  Forecast  History  Table. 

This  table  contains  a  copy  of  each  Class  V  Daily  Forecast  Record,  with  the  most  recent  record 
listed  on  top. 

4.6.  Requisition  &  Report  Generation  Dialog. 

Although  there  is  interest  at  the  unit  level  regarding  the  ability  to  generate  supply  requisitions 
with  the  SLDA,  the  development  of  this  capability  is  beyond  the  scope  of  this  phase  of 
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development.  Also,  there  was  no  discussion  with  stakeholders  on  the  type  or  format  of  reports. 
It  is  assumed  that  part  of  the  SLDA’s  further  development  will  eventually  include  both  of  these 
capabilities,  so  a  provision  should  be  made  to  accommodate  these  functions  in  the  future. 
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Chapter  5:  Other  Non-Functional  Requirements. 

5.1.  Security  Requirements. 

Determined  by  PM-LIS/TLDD 

5.2.  Special  User  Requirements. 

5.2.1.  Backup  and  Recovery. 

Sinee  the  normal  method  of  back-up  and  data  recovery  for  a  PDA-type  device  involves  the 
identification  and  synchronization  with  a  “parent”  computer  system,  it  is  assumed  that  the  SLDA 
will  perform  these  functions  in  a  similar  manner.  The  exact  method  of  synchronization  (direct 
connection,  wireless)  will  be  determined  by  PM-LIS/TLDD.  The  parent  computer  can  be  used  to 
store  the  complete  transaction  and  forecast  history  from  the  SLDA  if  it  becomes  necessary  to 
truncate  the  historical  records  stored  in  the  SLDA  due  to  limited  memory  or  storage.  The  SLDA 
should  be  able  to  recover  its  last  known  state  from  the  parent  computer  through  the 
s5mchronization  connection. 

5.2.2.  Data  Retention. 

The  only  tables  that  will  increase  in  size  during  operation  of  the  SLDA  are  the  forecast  history 
tables.  They  should  retain  the  minimum  amount  of  data  necessary  for  forecasting  based  on 
historical  data,  and  previous  records  can  be  archived  on  the  parent  computer  as  described  in 
paragraph  5.2.1. 

5.2.3.  User  Training. 

Determined  by  PM-LIS/TLDD. 
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Chapter  6:  Future  Development. 

6.1.  Validate  and  Verify  Class  I  Forecasting  Approach. 

The  method  of  basing  a  Class  I  foreeast  on  planning  values  determined  from  aetual  data  needs  to 
be  tested  through  aetual  experience.  The  published  planning  values  have  long  been  used  as  a 
basis  for  forecasting  supply  needs,  but  since  the  SLDA  makes  use  of  historical  data  once  enough 
data  has  been  recorded,  its  results  should  be  evaluated  through  field  testing  to  determine  if  the 
approach  works. 

6.2.  Develop  historical  data  forecasting  for  Classes  III  and  V. 

If  the  approach  used  for  Class  I  is  valid,  a  similar  method  could  be  explored  for  Classes  III  and 
V.  Also,  planning  values  for  Class  III  package  and  Class  V  could  be  incorporated  to  allow  the 
same  method  used  for  Class  I  to  be  employed  for  the  other  classes  (as  shown  in  Figure  4  and 
Figure  5). 

6.3.  Resource  Planning. 

Another  aspect  of  logistics  planning  at  certain  levels  is  transportation  planning.  A  further 
development  for  the  SLDA  could  include  a  means  of  determining  whether  the  requested  supplies 
can  be  transported  with  available  assets,  or  if  a  request  must  be  made  for  additional  support. 

6.4.  Automated  Requisitioning. 

As  previously  noted,  future  SLDA  development  could  include  the  ability  to  turn  the  forecast 
output  into  an  automated  requisition.  It  was  assumed  that  this  task  would  be  handled  by  a 
separate  application,  but  that  the  SLDA  would  provide  the  necessary  data  objects  to  be  used  by 
an  automated  requisition  application. 
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Appendix  A:  SLDA  Diagrams 


Figure  2:  Diagram  of  Set-Up  Dialog 
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Blue  arrows  indicate  general  program  flow 
Bta^  arrows  indicate  two>way  data  exchange 
Purple  arrows  indicate  table  referencing 


Figure  3:  Diagram  of  Class  I  Forecast  Dialog 
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Figure  1:  Diagram  of  Class  Iff  Forecast  Dialog 


28 


/  Carried  over  from 

Class  HI  dialog 


Appendix  B:  Functional  Hierarchy 


1.0  Receive  relevant  inputs 

1 . 1  Set  default  inputs 

1.1.1  Unit  information 

1.1. 1.1  Name 

1.1. 1.2  Type 

1.1.2  Local  time  and  date  (from  system  or  entered  as  difference  from  GMT) 

1.1.3  Equipment 

1 . 1 . 3 . 1  Vehicles  (quantities  by  t5q)e) 

1.1. 3.2  Weapons  (those  not  integral  to  vehicles  in  1.1. 3.1) 

1 . 1 .3 .3  Advanced  functions 

1.1. 3. 3.1  Change  default  consumption  factors 

1.1.4  Basic  Load  Data 

1.1.5  Re-supply  interval  (24  or  48  hours) 

1 .2  Dynamic  inputs 

1.2.1  Personnel  status 

1 .2. 1 . 1  Total  persoimel  counts  &  counts  of  personnel  with  special  meal 
requirements,  covering  three  re-supply  periods 

1 .2. 1 .2  Ration  cycles  for  next  three  re-supply  periods 

1 .2.2  Mission  Data  (Dynamic  list  containing  the  following  elements.  A  new  entry  is 
started  if  one  of  the  elements  changes.  Should  always  reflect  mission  details  for  the 
next  three  re-supply  periods) 

1.2.2. 1  Time  of  event 

1.2.2. 2  Mission  type  (offensive,  defensive,  movement) 

1 .2.2.3  Mission  terrain  (cross-country,  road,  idle) 

1. 2.2.4  MOPP  level 

1.2.3  Current  equipment  and  supplies  status 

1 .2 .3 . 1  Deadlined  equipment 

1 .2.3 . 1 . 1  Pacing  items 

1.2.3. 1.2  Rolling  Stock 

L2.3.L3  Other 

1. 2.3.2  On-hand  supplies 

L2.3.2.1  Class  I  (rations  and  water) 

1 .2.3 .2.2  Class  III  (bulk  and  package  petroleum  products) 

1. 2.3.2. 3  Class  V  (ammunition) 
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2.0  Provide  forecasts  for  next  three  re-supply  operations 

2.1  Class! 

2.1.1  MREs  by  type  (quantities  for  individual  meals  and  for  cases) 

2.1.2  Hot  A’s  and  unitized  groups  rations  (UGR)  by  number  of  meals 

2.1.3  Water,  bulk 

2.1.4  Water,  bottled 

2.2  Class  111 

2.2.1  Bulk  fuel 

2.2.2  Package  POL 

2.3  Class  V 

3.0  Generate  requisitions  and  reports 

3.1  Requisitions 

3.1.1  Class  1 

3.1.2  Class  111 

3.1.3  Class  V 

3.2  Reports  (review,  edit,  send) 

3.2. 1  Reports  to  next  higher  echelon 

3.2.2  Report  to  SPO 

3.3  Historieal  reports 
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Appendix  C:  Equations 


1.  MRE  forecast  (each  MRE  type),  24-hour  re-supply  interval,  next  day  (D+1): 


F  = 

MRE 


2.  MRE  forecast  (each  MRE  type),  48-hour  re-supply,  next  two  days: 


F  = 

MRE 


•  K.X 


■  -^^mre{^d.x~^d.^)'^ 


O  .  D 

*^n+2  "  ^D+2 


3.  MRE  forecast  (each  MRE  type),  24-hour  re-supply,  D+2  and  D+3: 


for^  =  2,3 


F  = 

MRE 


4.  MRE  forecast  (each  MRE  type),  48-hour  re-supply,  D+3  through  D+6: 


c  ,  n 

r  _  ‘^D+i  '  -^D+k 

^  MRE  ^ 


+  for/fe  =  3,5 

c 


5.  Water  forecast  (default  planning  value),  24-hour  re-supply  interval,  next  day  (D+1): 


W  =  S  P 

Ji+1  (Climate,  MOPP)i,^ 


6.  Water  forecast  (default  planning  value),  48-hour  re-supply  interval,  next  two  days: 

W  =  S!  •  P  +  H  (s  —  H  )-i-  S  •  P 

''  *  ■‘(Climate, MOPP)d„  IPco  /  ’ ''(Climate,  MOPP)d,_2 


7.  Water  forecast  (default  planning  value),  24-hour  re-supply  interval,  D+2  and  D+3: 


(Climate,  MOPP)i, 


for  k  =  2,3 


8.  Water  forecast,  (default  planning  value),  48-hour  re-supply  interval,  D+3  through  D+6: 

W  =  S  •  P  +  S'  P  for  yJ:  =  3  5 

(Climate, MOPP)o,k  ^  ■*  (Climate, MOPP)^,,^,,)  ’  ^ 


9.  Water  consumption  rate: 

w  +{h  -h  J 

Pn-\  o  * 


where  n  represents  the  current  day 
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10.  Student’s  t  statistic  for  water  forecasting: 


t 


Water 


^  vvhere  P„ 

K/3) 


Climate,  MOPP 


is  the  planning  figure 


being  tested,  p  is  the  mean  of  the  four  caleulated  water 
consumption  rates,  and  a ^  is  the  standard  deviation  of  the  four 
calculated  water  consumption  rates. 


Legend: 

/S'.  :  the  number  of  soldiers  (by  MRE  type)  assigned  on  day  i 
R. :  the  number  of  MREs  in  the  ration  cycle  on  day  i 
C :  the  number  of  MREs  per  case 
:  basic  load  for  item  k 
:  on  -  hand  quantity  for  item  ^  on  day  / 

P  \  planning  value 

/S'j, :  total  number  of  soldiers 

[  ~|  is  intended  to  represent  a  ceiling  function  (round  up  to  nearest 
integer) 
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